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Preprocessor for a predetermined document type 
definition, system for processing markup language 
documents, and method and computer program product for 
5 this purpose 

DESCRIPTION 

Technical field 

10 

The invention relates to a preprocessor for a 
predetermined document type definition (DTD) having 
interfaces to application units and having a markup 
language processor, to a system which includes this 
15 preprocessor for processing markup language documents, 
to a method for producing valid markup language 
documents which are conforming with a specific DTD, and 
to a computer program product for implementation of 
this method. 

20 

Prior art 

The use of markup languages for recording and 
structuring information is becoming increasingly 

25 important. The generation as well as the processes for 
reading and use of the information stored in markup 
language documents may, however, quickly indicate the 
limits of generic processors with regard to their 
processing, as well as limits relating to the 

30 standardized language scope of specific markup 
languages, and may lead to the necessity for 
supplementary data processing programs in order to make 
it possible to store and call information which can be 
utilized. These problems will be explained in the 

35 following text using an example from the field of power 
generation and distribution, although comparable 
problems may also occur in other fields, and the 
present invention is also aimed at providing a solution 
in these fields. 
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IEC Standard 61850 may be regarded as the future 
Standard for data interchange in station control 
technology. Its aim is to allow manufacturer- 
independent application interoperability between the 
5 various components and apparatuses in a station control 
system (Substation Automation System, SAS) . Part 6 of 
this Standard specifies the Substation Configuration 
Language (SCL) , in order to allow interoperable 
interchange of communications system configuration data 
10 between apparatuses and system configuration tools from 
different manufacturers. SCL can be used to describe 
widely differing aspects of a station control system, 
such as: 

15 the configurations of existing intelligent electronic 
apparatuses, 

the configurations of the communications system, 

20 the topology of the switchgear assembly, and 

its relationships with the functionality implemented in 
the internal electrical apparatuses. 

25 In order to ensure compatibility with the important 
information technology standards, SCL is based on the 
page description language XML (extensible markup 
language), Version 1.0. Part 6 of IEC 61850 includes a 
Document Type Definition (DTD), which defines the 

30 specific XML syntax for SCL documents and their 
semantics . 

The configuration states (which can be described using 
the SCL) of a station control system are in any case 
35 stored in the form of SCL-conf orming XML documents. 



XML is a Standard for representing information in 
document form. XML is one of the so-called markup 
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languages which are used for structuring documents or 
general information. A distinction is in this case 
drawn between so-called meta languages, which allow the 
definition of different markup languages and, for their 
5 use, require specification in the form of command and 
identifier definitions for the elements, and actual 
markup languages which relate more specifically to the 
structuring since they have a predetermined identifier 
and command scope. Markup languages include, for 

10 example, GML, SGML, HTML and XHTML as well as XML 
itself. XML documents are documents which structure 
data, but do not format it. The individual entries in 
an XML document are, in fact, associated with specific 
meaning contents. XML allows information to be 

15 structured on the basis of the sense of its content and 
hence, for example, goes beyond the HTML Standard, 
which was developed in parallel with it and which, for 
a predetermined scope of commands, defines only simple 
information structuring and, essentially, information 

20 relating to the presentation of the document (for 
example characters and their size) . The individual 
entries or elements in an XML document generally 
comprise a command, which is also referred to as a 
"tag" and which, for example, can represent the meaning 

25 of a specific information item, as well as data, for 
example text chains, to which the command in the entry 
can be applied. A so-called well-formed XML document 
includes at least one so-called prolog in which, for 
example, the XML version is stated, and a further 

30 element. In this case, the XML specification defines 
only how XML documents are to be produced, but not the 
type of information which can be stored in an XML 
document. The definition of such permissible tags is in 
fact based on document type definitions (DTD), which 

35 indicate definitions of the permissible entries in an 
XML document which is conforming with a respective DTD. 
For the purposes of the present invention, the 
expression document type definition shall be understood 
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as meaning any expanding definition of the structure of 
markup language documents, irrespective of whether such 
expansions are or are not provided in the definition of 
the markup language (that is to say going beyond the 
5 "permitted" scope of the language definition) . 

Such a DTD actually represents the definition of SCL 
documents. If an XML document is not only well-formed 
but also complies with the rules of an existing DTD as 
10 well, then this is referred to as a valid document. The 
DTD may either be referred to in the prolog, or may be 
included in the document. 

Various programming interfaces have been developed in 

15 order to make it possible to produce, read and modify 
XML documents (or documents in other markup languages) . 
These are so-called application programming interfaces 
(API) . An API defines the rules and conventions which 
describe how a piece of software can be used by another 

20 piece of software. When using such an API for access, 
the data in XML documents is represented, by way of 
example, in the form of structures which have branches 
like a tree (the so-called Parse tree) and have nodes, 
and which can be interpreted by means of suitable 

25 programs. One of these APIs is the Document Object 
Model (DOM) . The use of DOM-API thus requires 
navigation through XML documents in terms of generic 
nodes, in which case a node may correspond to an 
element, an attribute, a comment etc. The actual XML 

30 data, that is to say the values of the attributes and 
elements, is transferred in both directions in the form 
of character strings. 

In addition to DOM, there , are other interface 
35 specifications, for example the DOM Level 2, Simple API 
for XML (SAX), or Java API for XML parsing (JAXP) 
expansions . 
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DOM and other APIs for access to documents in the 
format of a markup language are merely specifications, 
and need to be converted into specific programs. This 
is done by means of processors which are able to record 
5 the content of, for example, XML documents and to 
present it to API-calling programs such that it 
complies with the DOM specification or some other API. 
Other programs may thus submit queries to the XML 
processor via an API-conforming interface by sending 

10 information to this XML processor via the interface, 
containing commands and/or contents such as text or the 
like, using the API format. The marker language 
processor responds to the transmission of information 
containing queries relating to the structure of an XML 

15 document by transmitting return information which 
provides the requesting program with information on the 
structuring of the processed markup language document. 

Currently existing API-conforming markup language 
20 processors, for example an XML processor that is 
available from Microsoft, are, in fact, generic in the 
sense that they do not offer support for a specific 
DTD. This means, for example, that attribute values are 
not checked against the attribute type, so that, for 
25 example, any NMTOKEN can appear in an element which is 
characterized as ENUM. There is no check to determine 
whether this value is included in the list of permitted 
values . 

30 Furthermore, content restriction rules (containment 
constraint rules) which define the multiple or 
conditional content of an element are not checked and 
no specific, semantic checks are carried out, for 
example to determine whether the "voltage" attribute 

35 actually contains a number together with a voltage 
unit. Using a generic API-conforming markup language 
processor, it is therefore possible to produce 
documents (with a specific DTD) , for example SCL 
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documents, which are well-formed XML files. However, 
there is no guarantee that such a document is also a 
valid XML file, for example a valid SCL file. Even if 
the file is valid, there is no guarantee of semantic 
5 correctness. Only when a specific markup language 
document is loaded does a generic markup language 
processor check it against the DTD that is being used, 
for example the SCL-DTD, although no specific error 
information is produced. The semantic correctness 
10 cannot be checked on the basis of the DTD, since the 
DTD defines only the syntax, but not the semantics of 
markup language documents. 

For the configuration of a station control system, this 
15 would mean that SCL files produced by means of a 
configuration tool having a generic XML processor could 
possibly be invalid or semantically incorrect. If a 
file produced in such a way is passed to an intelligent 
electronic appliance that is to be configured, the 
20 following situation could occur: 

- If the SCL file is invalid, the process of loading it 
into the appliance could fail. 

25 - If the SCL file is semantically incorrect, the 
process of configuring the intelligent electronic 
appliance would fail, or the intelligent electronic 
appliance could be configured incorrectly. 

30 In order to avoid this disadvantageous situation in the 
prior art, each configuration .tool, and the software of 
each configurable appliance that can read or write SCL 
files, is equipped with its own specific SCL module, 
which checks the SCL syntax and semantics when 

35 producing or reading SCL files. 

This is associated with increased programming 
complexity and, owing to the different implementations, 
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can also possibly lead to incompatibilities, for 
example when files are processed by a number of 
appliances . 

5 The object of the present invention is thus to provide 
an improved system, which ensures the correctness of 
markup language documents which are intended to comply 
with a specific DTD. 

10 Description of the invention 

This object is achieved by providing a preprocessor for 
a predetermined document type definition as claimed in 
the independent patent claim 1, by a system for 

15 processing markup language documents as claimed in the 
independent patent claim 14, by a method for producing 
markup language documents as claimed in the independent 
patent claim 21, and by a computer program product as 
claimed in the independent patent claim 27. Further 

20 advantageous embodiments, aspects and details of the 
present invention can be found in the dependent patent 
claims, in the description and in the attached drawing. 

The object is based on the principle of providing a 
25 specific preprocessor which, firstly, is able to 
interchange data with a generic markup language 
processor and, via this processor, to produce and read 
correct DTD-conforming markup language documents and, 
secondly, can provide an interface to any desired 
30 application apparatuses. It is self-evident that the 
present invention is not restricted to the processing 
of SCL documents even if, in the introductory part, the 
existing problems have been described with reference to 
SCL documents for station control technology. In fact, 
35 the present invention can in principle be used for 
processing markup language documents in which the 
guestion relates to the correctness and conformity with 
a specific DTD. 
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Due to the increasingly widespread use of markup 
languages such as XML, SGML or HTML, the invention has 
a wide field of application. 

5 The invention is thus based on a preprocessor for a 
predetermined document type definition (DTD), having 
at least one predetermined interface for interchanging 
information with interfaces of application units; and a 
conversion means for converting application information 

10 from an application unit to calls to a markup language 
processor, with the calls at the same time satisfying 
the DTD, and for converting markup language information 
from the markup language processor to return 
information for transmission to an application unit, in 

15 which case the converted return information can be 
interpreted by the application unit. 

In the present invention, as in the field of data 
processing in general, the term preprocessor means a 
20 program object which converts incoming data on the 
basis of specific criteria, and outputs the converted 
data . 

The preprocessor has a predetermined interface for 
25 connection to application units. This advantageously 
means that, once this interface has been defined, the 
preprocessor can be accessed from widely differing 
application units. This avoids the problem, which is 
known in the prior art, of reprogramming corresponding 
30 software modules in each individual application unit. 
When programming the application units, only a 
(simpler) functionality need then be implemented in 
order to call the predetermined interface of the 
preprocessor . 

35 

The preprocessor according to the invention can be 
implemented in a functional unit with the generic 
markup language processor. This means that the two 
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functionalities are combined in a single software 
object, so that the communication between the two parts 
can be initiated internally, without specific, defined 
interfaces needing to be introduced. 

Alternatively, the preprocessor can be inserted between 
different application units which can use it and a 
conventionally generic markup language processor, and 
can be coupled to both via interfaces. In this way, it 
is possible to use an existing generic markup language 
processor, so that the programming complexity to 
implement the invention is reduced considerably. 

The preprocessor includes a conversion means, which in 
each case matches the various structures of the 
information interchanged between the application 
apparatuses and the markup language processor to the 
needs of the opposite end and, furthermore, processes 
the calls supplied to the markup language processor 
such that they correspond to the respectively used DTP. 
The expression application unit should in this case be 
regarded in the widest sense and, in addition to 
configuration tools such as programs for a control 
computer or specific mobile configuration appliances, 
also includes configurable, intelligent electronic 
apparatuses for station control technology, the 
communications system used for station control 
technology, and all the other elements . 

For applications other than those relating to station 
control technology, an application unit should be 
regarded as any unit, irrespective of whether this is 
in the form of hardware (for example in the case of 
appliances with a built-in ASIC for processing markup 
language files) or software, operating with markup 
language documents which have to comply with a specific 
DTD. 
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The markup language processor is a processor which is 
able to process files in the format of the markup 
language, that is to say to produce, to modify and to 
read them. The files processed by the markup language 
5 processor may include widely different information 
relating to one or more appliances to be configured. 

The preprocessor preferably interacts with a markup 
language processor which is conforming with a 
10 predetermined API , with the preprocessor having at 
least one interface for transmitting calls to the 
markup language processor and for receiving markup 
language information from the markup language 
processor, and the calls are API-conforming calls. 

15 

For the purposes of the present invention, API- 
conforming means that the markup language processor has 
a programming interface which can receive method calls 
and can output information which corresponds to the 

20 definition of a specific API. The data is thus 
interchanged via the API-conforming interface of the 
markup language processor, so that the preprocessor 
must be able to generate corresponding commands. 
The markup language that is used is preferably XML, 

25 since this is an established Standard, allows 
information to be structured easily, existing software 
can easily be adapted, and the language is well 
understood, since it is well known. 

30 The API which is used may be any suitable API which can 
reflect the markup language that is used and which 
allows necessary manipulations to the documents, such 
as SAX or DOM when using XML. 

35 The preprocessor according to the invention may 
preferably be an SCL preprocessor, that is to say one 
that is suitable for processing information in such a 
way that it checks with the SCL-DTD before passing it 
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on to a requesting application unit, thus making it 
possible to avoid configuration errors. The use of a 
preprocessor specifically for generating and reading 
SCL documents unexpectedly solves various problems 
5 which have been found in the prior art, as described 
above, and hence simplifies the design and 
implementation of administration systems for station 
control technology . 

10 Information which is passed via the interfaces is 
transmitted between the application units, the 
preprocessor according to the invention and the markup 
language processor. In this case, it is possible to 
distinguish between different information items. The 

15 information sent from an application unit to the 
preprocessor is referred to, according to the 
invention, as application information . This information 
should be transmitted in a standardized format, which 
corresponds to the software interface of the 

20 preprocessor. The application information generally 
includes instructions for manipulations to the markup 
language file. If the application unit is a 
configuration tool, the input parameters of the 
configuration tool may be quoted as application 

25 information and may be sent to the preprocessor 
together with the appropriate instructions for 
manipulation of the markup language file. If the 
application unit is an intelligent electronic 
appliance, typical application information may be, for 

30 example, a check relating to the contents of the markup 
language file. In one situation, in addition to pure 
instructions, structure information, that is to say 
information relating to the actual content of a markup 
language file to be produced and relating to the 

35 syntactic relationship between such information items 
is thus likewise transmitted, while, in the other case, 
only an instruction is transmitted. 
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The application information may preferably include 
appliance configuration parameters for producing a 
markup language document for the configuration of at 
least one configurable appliance. 

5 

The application information is converted in the 
conversion means to method calls which can be 
transmitted to the markup language processor. During 
this conversion process, the application information is 
10 at the same time changed to a form which is conforming 
with the DTD being used, in order to obtain a markup 
language file which is not only well formed, but is 
likewise valid. 

15 Markup language information which is sent from the 
markup language processor, such as information relating 
to the structuring of the processed markup language 
document, uses an API-conforming format in the opposite 
direction. The markup language processor thus transmits 

20 via the interface information, for example, relating to 
the generic nodes, such as elements, attributes, 
comments, etc. 

The conversion means according to the invention 
25 converts this information to return information, which 
can be transmitted to an application unit. It must be 
noted that this application unit need not be identical 
to the previously mentioned application apparatus which 
is transmitting information. Thus, in practice, it is 
30 frequently possible, particularly in the field of plant 
control systems, that a first application unit, for 
example a configuration program on a data processing 
system, produces or modifies a configuration file in 
the markup language format which, for example, is 
35 conforming with the SCL; and that a second application 
unit, for example a configurable appliance in a 
distribution substation, reads the data in this file, 
in order to configure itself. 
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According to the invention, it is preferable for the 
return information to include structure information 
relating to a DTD-conforming markup language file which 
is processed by the markup language processor. This 
5 structure information may in turn include identifier 
information, that is to say so-called tags, and/or 
content information, for example information relating 
to configurations when using SCL files. The return 
information may thus include appliance configuration 
10 parameters for an existing markup language document for 
the configuration of at least one configurable 
appliance . 

These appliance configuration parameters (as return 
15 information) and/or return information of any general 
type, are converted by the conversion means to 
converted return information, which can be interpreted 
by the application apparatus. This conversion to 
converted return information includes, firstly, a 
20 format conversion of the API-compatible return 
information to a parameter format which is likewise 
used by the respective application unit. 

Furthermore, the process of conversion to converted 
25 return information preferably likewise includes, 
however, a check relating to the DTD-conformity of the 
transmitted information, in order to ensure that, in 
addition to the mere format, syntactic and semantic 
conditions are satisfied by the return information sent 
30 back to the application apparatus. 

It is thus preferable for the conversion means to have 
means for checking the syntax of the received 
information for conformity with the DTD, and the 
35 semantics for compliance with the conditions of the 
respective application unit to be configured. This 
check is carried out both with regard to the 
application information and with regard to the return 
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information transmitted by the markup language 
processor. This makes it possible to ensure that the 
syntax of the transmitted information complies with the 
DTD being used such that, firstly, the application unit 
5 can receive information which can be utilized and, 
secondly, the markup language processor is able to 
produce valid markup language documents in the 
respective DTD format. 

10 Even when a valid markup language document with a 
specific DTD is present, it is possible for the 
transmitted information to be incorrect, or 
unacceptable, for various reasons. Thus, for example, 
even if the type of transmitted information corresponds 

15 to the type of identifier responsible for it, the 
information which is actually transmitted may be 
outside an absolute maximum possible value range. 
Errors would then once again occur when using the 
markup language document. It is thus preferable for the 

20 conversion means to have means for checking the logical 
correctness and/or permissibility of structure 
information included in the information. To do this, it 
may be necessary to supply the preprocessor with 
further information which includes, for example, 

25 appliance-specific presets for producing SCL files, 
since the permissibility may differ from one 
configurable appliance to another configurable 
appliance . 

30 The invention is furthermore based on an overall system 
which includes a preprocessor according to the 
invention. This is a system for processing valid markup 
language documents which are conforming with a specific 
document type definition (DTD) with the system having 

35 an application unit for producing and/or reading a set 
of application information items, a preprocessor 
according to the invention, and a markup language 
processor for interchanging information with the 
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preprocessor, in order to process a markup language 
document which is valid with respect to the DTD. 

All that has been said above with regard to the 
5 preprocessor according to the invention applies equally 
to the system, so that reference is made to the entire 
contents of what has been stated above. 

In particular, the preprocessor and markup language 
10 processor may be combined to form a functional unit. 

It is likewise preferable for the markup language 
processor to be a generic markup language processor 
with an API-conforming interface to the preprocessor, 
15 as is explained in detail above. 

According to the invention, the application unit may in 
this case be a configuration program or a configurable 
appliance. The system is thus able not only to produce 
20 DTD-conforming markup language documents but also in 
turn to read them, and to provide the information to an 
appliance which is to be configured, when the latter 
produces a request. 

25 The application information items may be appliance 
configuration parameters for configuration of a 
configurable appliance . 

In a corresponding way, the predetermined DTD may, for 
30 example, be the Substation Configuration Language 
(SCL) . 

Furthermore, the invention is based on a method for 
producing markup language documents which are 
35 conforming with a predetermined document type 
definition, with the method having the following steps: 



- production of a set of application information items; 
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- production of an information representation, which is 
conforming with the predetermined DTD, from the 
application information; and 

5 - production of a markup language document, which is 
valid with respect to the DTD, from the information 
representation. 

The application information items which are used may 
10 preferably be appliance configuration parameters for at 
least one configurable appliance. A set of appliance 
configuration parameters is normally produced by means 
of user inputs in a configuration program. These 
appliance configuration parameters are used to produce 
15 a parameter representation, which is conforming with 
the DTD being used. For example, as mentioned above, 
this may be done in a preprocessor according to the 
invention. The parameter representation may, for 
example, be a parameter representation which is 
20 conforming with a specific API. 

In a final step, the parameter representation which is 
produced is converted to a markup-language-conforming 
configuration file. This step may be carried out, for 
25 example, after transmitting the parameter 

representation via the API interface in a conventional 
markup language processor. 

It is preferable for the appliance configuration 
30 parameters to be checked syntactically and/or 
semantically before the DTD-conforming parameter 
representation is produced from them. 



35 



It is likewise possible to check that the sense of 
their content is correct, as described above with 
reference to the preprocessor. 
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The invention may be characterized in that the process 
of producing the valid markup language document has the 
following steps : 

5 - production of calls from the DTD-conforming 
information representation, which are conforming with a 
predetermined API; 

- transmission of the API-conforming calls to a markup 
10 language processor via an interface which is conforming 

with this API; 

- execution of the API-conforming calls in order to 
process the valid markup language document. 

15 

Furthermore, in the method according to the invention, 
the application information items may be appliance 
configuration parameters for at least one configurable 
appliance. The API-conforming instruction structures 
20 can be produced by means of a preprocessor according to 
the invention . 

Furthermore, the opposite processing direction, that is 
to say the parsing of a markup language document by 
25 means of a markup language processor and the conversion 
of the information obtained in this way to application 
return information for the application unit, is also 
intended to be covered by the invention. 

30 Finally, the invention is also based on a computer 
program product which can be loaded into an internal 
memory in a digital data processing means and has 
computer program code means which execute the method as 
claimed in the invention when they are loaded and run 

35 in one or more data processing means. The computer 
program product thus describes and implements the 
preprocessor according to the invention. The computer 
program product is preferably a computer-legible medium 
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with a computer program stored in it in order to carry 
out the method according to the invention. 

Brief description of the drawing 

5 

Figure 1 shows, schematically, the arrangement of the 
various elements in the conversion system according to 
the invention. 

10 Ways to implement the invention 

One important aspect of the invention is to provide a 
specific reusable preprocessor, for example an SCL 
processor, as a software product which can be used for 
15 any software (application unit) which accesses the 
respective markup language documents. This preprocessor 
may be implemented, for example, by means of 
Microsoft (TM) , COM components, the script systems PHP 
or Perl, or by means of Java(TM) classes. 

20 

This preprocessor has the following important features: 
all the necessary syntactic and semantic checks are 
carried out as early as possible. This can be achieved 
by providing specific interfaces which are implemented 

25 for each element defined in the DTD, for example the 
SCL elements in accordance with IEC 61850, with 
specific methods for setting attributes, adding 
elements etc., which can carry out all the necessary 
steps, and which can return an error message in the 

30 event of incorrect input parameters, such as incorrect 
application information or incorrect API-conforming 
information from the markup language processor. 

Furthermore, the preprocessor can be equipped such that 
35 it limits the capabilities for user inputs in such a 
way that only correct information can be entered in the 
DTD document that is produced. This can be achieved by 
only specific DTD interfaces being accessible which, 
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for example, do not allow the addition of an attribute 
which does not exist at all for a given element of the 
DTD. 

5 Finally, the provision of methods which allow 
convenient production of DTD-conforming markup language 
files, for example SCL files, and information to be 
obtained from such DTD-conforming markup language 
files, is a feature of one preferred embodiment of the 
10 preprocessor according to the invention. 

The preprocessor according to the invention can be 
based on an existing generic markup language processor, 
for example an XML processor. This in itself results in 

15 the provision of a large proportion of the 
functionality which is required, since the fundamental 
behavior of an XML processor and of the processor 
according to the invention are similar in some 
respects. As already explained, it is likewise possible 

20 to expand an existing markup language processor in 
order to integrate the lack of functionality of a 
preprocessor in it. 

Figure 1 shows, schematically, one possible design for 
25 the system according to the invention, based on the 
example of the administration of appliance 
configurations. In the upper line, a DTD document is 
produced by a configuration tool 1 sending its input 
parameters via a suitable interface to the preprocessor 
30 2. The latter converts the input parameters that have 
been received to calls to the, for example, DOM-APIs, 
which are sent via a further connection to a generic 
markup language processor 3, which provides an API 
interface 4 for this purpose. The markup language 
35 processor now uses the transmitted DTD-conforming 
appliance parameters to generate a DTD-conforming 
markup language file 5. The information which is 
produced is supplied, possibly via the markup language 
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processor 3, to the preprocessor 2, which transmits it 
to the configuration tool 1 in order, for example, to 
produce a display on the screen as feedback that the 
input was correct. 

5 

Access of a configurable appliance is described in the 
lower line. The configurable appliance, for example an 
intelligent electronic appliance 6, produces a request 
via a preprocessor 2, which may be identical to the 

10 preprocessor 2 for producing the DTD-conforming markup 
language file, and converts this request to an API- 
conforming method call, for example to a DOM-conforming 
call, and passes it on via the API-conforming interface 
4 thereof or of some other generic markup language 

15 processor 3, so that, after reading the configuration 
information included in the DTD-conforming document, it 
can transmit return information, processed as API- 
conforming information, to the preprocessor 2, which 
converts it to corresponding parameters which can then 

20 be read by the appliance 6, which can then configure 
itself autonomously . 

The preprocessor 2 and the markup language processor 3 
have identical reference symbols in the upper line of 

25 Figure 1 (production) and in the lower line of Figure 1 
(reading) in order to illustrate the fact that this may 
be the same processor in each case, which can process 
both types of requests from different application 
units. Two boxes are in each case shown, in order, on 

30 the other hand, to make it clear that different 
processors may also access one document. 

The functional elements comprising the preprocessor 2 
and the markup language processor 3 may be combined to 
35 form a unit. In this case, there is no need to use a 
markup language processor with a predetermined API- 
conforming interface 4, since the elements can 
communicate internally. 
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The availability of the specific preprocessor according 
to the invention, for example an SCL processor, with an 
SCL-specific interface, has various advantages. For 
example, there is an improvement to the error checking 
5 during reading and writing of the markup language files 
that are produced. The amount of effort required for 
design and implementation is reduced due to the 
reusability of the preprocessor. It is thus possible to 
market new products more quickly. By focusing on a 

10 small number of software products, it is possible to 
improve the quality of the software, which in turn 
leads to a reduction in the test effort. The 
preprocessor according to the invention may thus 
represent an important integral component of future 

15 station control technology and can be marketed as a 
software product both therein and in further 
application fields . 
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Configuration tool (application unit) 
Preprocessor 

Markup language processor 
API -conforming interface 

DTD-conforming markup up language document 
Configurable appliance 



